Resource Management

ABSTRACT

The invention relates to a method, device and system for management of resource in a communication network having a resource owner (RO) providing the resource and at least one resource user (RU) using the resource. According to the present invention a resource broker is introduced between the resource owner and the at least one resource user. Said broker is arranged to perform a management procedure for deciding whether to perform an allocation, keeping or release of resource. In order to take a decision a resource usage measure (TTL) is used. In accordance with the present invention said measure is updated when user&#39;s usage measure (Keep Alive, InterestMsg) informing about the expected usage of the resource by a resource user is obtained. The update is performed by means of a cumulative algorithm taking into account current and past values of the resource usage measure (TTL).

TECHNICAL FIELD OF THE INVENTION

The present invention relates to method, device and system formanagement of resources for telecommunications networks. The managementcomprises allocation, release or keeping of the resource.

Telecommunications networks, such as the third-generation wirelessnetworks (UMTS Universal Mobile Telecommunication System) or high-speednetworks such as asynchronous transfer mode networks aim to provideservices such as voice, data, and multimedia via computing devices overnetwork infrastructures. To support various services with a certainquality of service (QoS) requirement, resource provisioning is a majorissue. In each case, the communications networks include at least oneresource, which is to be managed in an appropriate way.

A number of applications in the current telecommunication systems areone-to-many applications, where one or a few sources are sending to manyreceivers. An efficient way to support this type of transmission is touse multicasting. Multicasting is an internetwork service that permitssources to send a single copy of a data packet to an address that causesthe data packet to be delivered to multiple receivers. Undermulticasting only one copy of a message will pass over any link in thenetwork and copies of data packets will be done only where pathsdiverge. Furthermore, there is performance improvement for the sender ifit is sufficient to send only one copy of a message, even if the messageis going to a huge number of recipients. In case of the multicasttransmission, the network connections are reserved for a number of usersand also the server is accessed by a number of users so that itsresources are to be distributed amongst the users, meaning thatresource's provisioning considers the number of users sharing theresources.

The number of clients using a resource can vary and vanish in certainpoint of time. In case the resource is not used for a long period oftime it may be released or destroyed. This kind of resource may be aserver function temporarily allocated to a certain node of the network,an anycast, broadcast or multicast “association” e.g. used for transportpurposes, a signaling relation between nodes and alike. The problem ofshared resources occur not only for transport issue, but it may alsoapply for processing, storage capacity etc.

As mentioned above provisioning of resources, in particular of sharedresources is one of the major issues in a network and call admissioncontrol is one of the provisioning strategies to limit the number ofcall connections in the networks in order to reduce the networkcongestion and call dropping. One call admission model is used fortraffic shaping, which is for example applied for determination if adata flow should be allowed to send. The simplest traffic shapingschemas try to shape all traffic into isochronous flows with regularamounts of data being emitted at regular intervals. An example of thesimplest traffic shaping schemas is the simple Leaky Bucket. FIG. 7illustrates the leaky bucket schema. Incoming data flow in form of datapackets 70 is placed into bucket 71. The data packets drain out thebottom of the bucket 72 and are sent on the network at rate g. Thebucket size, B, limits how much data may be in the bucket waiting forinput into the network. If the data flow carries more data than thebucket can store, the excess data is discarded. Typically, each dataflow has its own leaky bucket. Conceptually, each host is connected tothe network by an interface containing a leaky bucket, that is, a finiteinternal queue.

Once the resources are established, call admission algorithms are usedto control the usage of reserved resources. Another aspect is therelease of the allocated resources.

Besides multicast there are a number of further examples for which theproblem of resources management occurs, like for example broadcast oranycast as a transmission means. Furthermore said problem occurs also inpoint-to-point communication, wherein a number of point-to-pointconnections build a virtual pipe or tunnel within a network, which is tobe shared. Moreover the resources management problem occurs also by anyassociations issues, for example in case of SCTP stream controltransmission protocol established between a client and its server.Herein the SCTP association between a server and a client is theresource, which in fact comprises memory and processing capacity in boththe client and the server, and network capacity used for maintaining theassociation, wherein there is the necessity for an appropriate resourcemanagement.

It should be noted that a resource is in a “soft state” if itsreservation expires or is destroyed by a server or by an entityresponsible for resource management, after not being used for a certainperiod of time. Otherwise it is called a “hard-state” resource.

The cost of keeping an idle resource frequently is higher than the costof releasing or destroying it and after an idle period seizing orcreating it again on a need basis. Another key reason for keeping idleresources is to avoid long resource setup times when the resource isneeded.

In the following an example is given for resource management in apoint-to-point connection. In wireless networks, such as in packetswitched GSM and WCDMA networks, a PDP-context is established. In thePDP context activation a mobile subscriber identity is associated withan IP address. During the PDP Context Activation a tunnel is created inthe network. During this procedure also a Quality of Service QoSnegotiation takes place between user's mobile station and the network.After the establishment of the PDP-context, said PDP-context is kept inorder for the user to send or receive content instantly rather thanfirst waiting until the PDP context is established.

For the aim of keeping resources active, different approaches fordifferent protocols were developed, such as Keep Alive mechanism,Resource Refresh messages and alike are currently used by differentnetwork standards (H.323, RSVP, NSIS, etc.) for the purpose of keepingcertain resources alive or in an active state. For example in the KeepAlive mechanism an instance (for example a server or a client) sendsfrequently a message or information included in a data packet (forexample in a header) indicating that the connection is supposed to bekept open although currently no data is being sent. Thus, in case thereis data for sending, the communication is carried out on the samealready established connection. This is continued until either theserver or the client decides that the communication is over, and one ofthem drops the connection.

Usually a Time To Live parameter is included in such messages, andcontrols live time of resources, so that a resource is not kept too longopen unnecessarily. This technique was developed for a point-to-pointconnection, wherein one instance informs the other about its readinessfor keeping the connection open. After a timer expires the connection isdropped.

Accordingly, existing technologies following the old practice when oneresource was allocated to one user, are using time to live parameter toreset the timers defining the resource live time. That kind of approachhardly takes into account various preferences of multiple users withinmulticast connection or of the resource owner, and does not evaluate theproactive or expected usage of the resource, because the establishmentand release of resources is currently based on either administrativeroutines or simple requests from resource users. These routines may beinaccurate and establish or release the resource too early or too late.

However, the problem does not only occur in the multicast transmission.In many cases existing technologies neither pose nor solve at all theproblem of releasing idle resources, and leave itimplementation-dependent.

SUMMARY AND DESCRIPTION OF THE INVENTION

It is an object of the present invention to provide a solution forefficient management of resources within a telecommunication network.

The invention is embodied in a method as disclosed in claims 1, 20 and25. Advantageous embodiments are described in the dependent claims beingdisclosed in the corresponding parts of the description.

The method of the basic idea is disclosed in claim 1, which discloses amanagement procedure being implemented in a resource broker.

The method according to the present invention for management of resourcefor a communication network having a resource owner (RO) providing theresource and at least one resource user (RU) using the resource performsthe following steps in the resource broker being introduced between theresource owner and the at least one resource user. In the first step aresource usage measure (TTL) is initiated. Said measure is used to trackexpected usage of a resource. The resource broker obtains user's usagemeasure (Keep Alive, InterestMsg) informing about the expected usage ofthe resource by a resource user. The user's usage measure can be eitherreceived as a message from a resource user or alternatively the resourcebroker calculates said measure based for example on reservationinformation or history information. In order to keep the resource usagemeasure (TTL) updated an update procedure for updating the resourceusage measure (TTL) with the user's usage measure (Keep Alive,InterestMsg) by means of a cumulative algorithm taking into accountcurrent and past values of the resource usage measure (TTL) isperformed. The common characteristic of the cumulative algorithm iscumulating of further values, in particular of the current resourceusage measure and the history of said value in order to compensate theeventual uncertainty of the received user's usage measure indicating theexpected usage of the resource by the resource user, which can beimprecise and have a certain degree of uncertainty. In this case thealgorithm compensates the possible uncertainty or randomness of theinformation arriving from users, by means of averaging the usage measureover time and different users.

In accordance with the established resource usage measure a decision ismade whether to perform a management action. For this purpose a checkingprocedure for checking the resource usage measure is performed. In casethe resource usage measure justifies performing of a management action,which can be allocation, keeping or release of resource, a correspondingaction is performed.

Since the cumulative algorithm considers the current and past values ofthe resource usage measure and additionally also the current andexpected needs of resource users, it is possible to forecast the usageof the resource, so that the resource would not be kept open in case itis not needed and closed even when users use said resource. Currentlysuch decisions are being made due to the statically set resource usagemeasure.

In respect to claim 18 a resource broker according to the presentinvention is disclosed. The resource broker is arranged to performmanagement of resource for a communication network having a resourceowner (RO) providing the resource and at least one resource user (RU)using the resource. Said resource broker (RB) is placed between theresource owner and the at least one resource user and comprises aninitiation means for initiation a shared resource usage measure (TTL).Further the resource broker comprises an obtaining controller forobtaining user's usage measure (Keep Alive, InterestMsg) informing aboutthe expected usage of the shared resource by a resource user. An updatecontroller is introduced for updating the shared resource usage measure(TTL) with the user's usage measure (Keep Alive, InterestMsg) by meansof a cumulative algorithm taking into account current and past values ofthe resource usage measure (TTL). For the purpose of checking theresource usage measure indicating the necessity to perform a resourcemanagement action a checking monitor is used. In accordance with theresult of the checking monitor a resource management action means isadapted for performing resource management action. The mentioned meansbeing part of the resource broker are arranged to perform the functionas described in respect to the corresponding method step.

It is proposed that the resource broker has further features. Forexample the resource owner provides unreliable resources for brokering,then the resource broker may work as a kind of owner of a resource pool,which manages resources and provides for their redundancy in case offailures.

Furthermore the present invention discloses a system for management of aresource for a communication network having a resource owner (RO)providing the resource and at least one resource user (RU) using theresource. Said system comprises a resource broker (RB) as describedabove, a first communication interface between said resource broker (RB)and the resource owner (RO) and a second communication interface betweensaid resource broker (RB) and the at least one resource user (RU).

In the following preferred examples of the present invention shall bedescribed in detail, in order to provide the skilled person withthorough and complete understanding of the invention, but these detailedembodiments only serve as examples of the invention and are not intendedto be limiting. The following description shall make reference to theenclosed drawings, in which

FIG. 1 shows a schematic representation of network architectureaccording to an embodiment of the present invention,

FIG. 2 shows a flowchart of a basic embodiment of the present invention,

FIG. 3 shows a schematic representation of signalling according to anembodiment of the present invention,

FIG. 4 shows a flowchart of an embodiment of the present invention forreleasing shared resource,

FIG. 5 shows a flowchart of an embodiment of the present invention forallocation of shared resource,

FIG. 6 shows a schematic representation of system architecture andinterfaces according to an embodiment of the present invention,

FIG. 7 shows a schematic representation of call admission according tostate of the art using leaky bucket schema,

FIG. 8 shows a schematic representation of an embodiment of the presentinvention for releasing resource using leaky bucket schema.

FIG. 1 shows a schematic representation of communication networkarchitecture according to an embodiment of the present invention, wherea new functional node, namely resource broker, RB, is introduced oncommunication link between at least one resource owner, RO, and at leastone resource user, RU.

It should be noted that the terms “resource owner”, “resource user”,“resource broker”, or generally “node” , “means” in the context of thepresent invention refers to any suitable combination of hardware andsoftware for providing a predetermined functionality in thecommunication network. In this way, said terms generally refers to alogical entity that can be spread out over several physical nodes of thenetwork, but can also refer to a physical entity located in one physicalnode.

In the examples described thereafter the function of a resource brokeris performed by servers or content providers, wherein a server can beresponsible for communication links in a network and content providerprovides content which is to be distributed to the users.

Preferably, the communication network is a mobile communication network,e.g. is a mobile communication network operating according to GPRS(General Packet Switched Radio) or UMTS(Universal Mobile TelephoneSystem) or GSM. However, the present invention is also applicable in anycommunication network providing resource.

It should be noted that the term “resource” designates any kind ofresource entity. In the present invention two kinds of resource sharingis disclosed; simultaneous sharing, which means that multiple resourceusers access a resource at the same time) and sequential sharing, whichmeans to have one resource user accessing a resource at the same time.

In the following, embodiments are presented showing simultaneouslyshared resource. Preferably, examples of said resources are networkresources that could be virtual entities in a communication network andseized or created for the common use of distributed users. Thereby,these might be the network connections being for example used formulticast/broadcast transmissions but also resources at certain networknodes, like for example processing time, or storage can be considered asshared resources according to the present invention. However the presentinvention is not restricted to simultaneously shared resource. In factthe proposed method can be used for resource management in case of asingle user of a resource. For instance the method can be used forrelease of any transmissions/connection associations, for example incase of SCTP stream control transmission protocol established between aclient and its server. As aforementioned, the SCTP association between aserver and a client is the resource, which in fact comprises memory andprocessing capacity in both the client and the server, and networkcapacity used for maintaining the association. In this case the serveris a resource owner and the client is a resource user and the procedureaccording to the present invention can be performed in order to decidewhether said association is to be maintained, this procedure can beperformed either by the client or by the server or independently by boththe client and the server. This control might be useful for an operatorin order to save the cost of resource association in a node. In thefollowing two embodiments are presented showing the applicability of thepresent invention for management of shared resources. However, the sameprocedure applies also for a resource being not shared.

It can be that the resource is a distributed entity and different nodesown/host different parts of the resource entity. Then it is reasonableto assign/ designate the resource owner function to several or all ofthe nodes sharing the ownership of the resource. In this case the logicof a resource owner and of a resource broker can be collocated in onenode. Even more each node sharing the resource ownership can have itsown resource broker logic. The node/logical entity that owns mostexpensive part of a distributed resource or has characteristics limitswhich in case of an overload may impact system/service availability canhave a more restrictive resource management procedures, so that inmajority of cases this node makes decisions on whether to reserve, keep,or release the resource. In this case each RO can play its own RB roleas well.

Returning to FIG. 1, it can be seen that in a network architecture morethan one resource owner can be placed. As mentioned above, there can bedifferent kind of resources available and each resource owner owns atleast one kind of said resource. Also, it is possible that one kind ofresource can be managed by each of the resource owner. However, oneresource, which is to be managed, has its own management procedure at aresource broker. Alternatively, each resource broker can be responsiblefor one resource.

According to FIG. 1 there is an interface, 11, between the resourceowners, RO, and the resource broker, RB, for indicating the availabilityof the resource to the resource broker. Further there is an otherinterface, 12, between the resource broker and the resource users forcommunicating with the users. Said interface is used for informing theresource broker about the user's readiness for usage of resource. Hence,the users can inform the resource broker by means of this interface, 12,whether they want to request a resource reservation, keep the resourcereserved or whether they want to release the resource. Furthermore thisinterface can be used for further communication purposes as this isdescribed in accordance with further embodiments of the presentinvention.

Preferably, the real data traffic does not need go via the resourcebroker. For example in case shared resource is communication link thenthe transmission goes over said link without involving the resourcebroker into the communication. The independence of resource usage fromthe management procedure of the resource is depicted in FIG. 1 by meansof a direct interface, 13, between resource owner and resource users.

Alternatively, the real data traffic goes via the resource broker. Forexample in case the resource broker RB is a logical part of the resourceowning node. In that case the resource usage traverses the resourcebroker, which may control if the resource usage is according to what wasindicated or requested. Furthermore the resource broker may use theresource usage for charging or statistical purposes.

FIG. 2 shows a flow chart of a basic embodiment of the method of thepresent invention with steps being carried out in the resource broker.The following steps are to be performed for management of a resource.Preferably, a resource broker manages a number of resources and thus anumber of management procedures according to FIG. 2 is to be performedin a resource broker. Alternatively, the management procedure could berun for each user separately and later on an algorithm harmonizing themultitude of the running procedures is to be carried out in order toreduce it to a single value (like a single TTL timer).

According to the method for resource's management shown in FIG. 2, saidmethod being carried out in the resource broker comprises step S21,where a resource usage measure is initiated. The initiation of theresource usage measure can be performed in any desirable or suitableway. For example, the resource broker can initiate it with a value,which the resource broker determines by itself. Alternatively, theresource owner can provide the value to the resource broker. For examplethe resource owner defines costs or time interval for the resources,which are sent to the resource broker for estimation the initiatingusage measure. The usage measure could be for instance Time To Use ormoney to spend in a certain period of time that is the combination(money, time interval). Furthermore, the resource owner can provideadditional information, like for example resource costs which can beused to influence the result of the update procedure.

Moreover the initiation phase can include the provision of associationsbetween a resource and the information related with said resource. Theassociation can be performed in any desirable and suitable way. Forexample resource broker can generate a local entry (for example resourceitem representation) when the resource owner grants permission to theresource broker for brokering a resource entity. Alternatively, thisstep can also be done via administration routines. The initiationprocedure results in the defined association, including for examplemodel type of the update procedure, its parameters and their initialvalues, for instance model=“leaky bucket”, measure-type=“average amountof money earned by resource owner in a specified period of time perseized resource”, the amount is specified by Reason-to-Live=“the actualamount of money sufficient for seizure of a resource entity” that latterswitches the resource on.

Additionally, also other parameters can be initialised, for instance theresource usage measure is set to a value defining time for keeping theresource open.

Subsequent to step S21, the method of FIG. 1 proceeds to step S25,wherein checking the resource usage measure is performed. Hereby thisstep can be performed in any preferable way, depending on the demands.For example it can include means for changing the resource usage measurein order to have a variable value allowing taking a decision. Theconnection between S21 and S25 allows detection of users' interest.Thus, in case no user's usage measure arrives, the procedure terminatesvia S25 in step S26, in which a corresponding resource management actionis performed.

In parallel the step S22 is conducted until a request from a user isreceived, which means the procedure waits for an event of receiving arequest informing about the interest of the users regarding the usage ofthe resource. The users are able to provide for example periodically aconsistent estimation of their expected usage of the resource by meansof the user's usage measure or a list of parameters, which facilitatethe computation of the measure in resource broker. Further example canbe that this information is provided with different intervals. Saidmeasure may be implemented as a kind of Keep Alive message, which isused in the following embodiment. However, there are different ways forimplementation of the user's usage measure besides sending a requestmessage. Some examples are given further in respect to FIG. 4.

Alternatively to sending a message including the user's usage measurefrom the resource users to the resource broker, the resource broker cancalculate the user's usage measure by itself. The calculation can be forexample based on a model type, history information and already receivedupdates for the resource.

It is to be noted that there can be a number of users accessing a sharedresource, meaning that requests arrive from different users, usually atdifferent and changing points in time. Also it should be that theinformation itself or the information values may differ over time and/orper user. Therefore it is proposed to have some kind of recognitionprocedure in order to put the accessing resource user into relation withthe running management procedure.

In on embodiment of the present invention it is proposed to have thefollowing solution. The resource user sends a request for a resource tothe resource broker and indicates a certain type of resource andpossibly a time interval for reserving the resource. When the resourcebroker reserves a resource entity for the resource user, the resourcebroker sends an ACCEPT message with the identity ID of the reservedresource entity or association ID. Later on if the resource user wantsto update the corresponding resource at the resource broker on theexpected resource usage the subsequent KeepAlive message refers to thevalid entity ID.

When a user's usage measure request for the resource arrives, S23, themethod proceeds to step S24, wherein an updating procedure for updatingthe resource usage measure with the user's usage measure by means of acumulative algorithm is performed.

It should be noted that the term “cumulative algorithm” in the contextof the present invention refers to any suitable method for performing acalculation of a new resource value taking into account furtherparameters, like current and past values of the resource usage measure(TTL) and the user's usage measure (KeepAlive). As an example in thefollowing description an approach based on Leaky Bucket method isdescribed. The Leaky Bucket is an algorithm currently used for SystemLoad Control and Call Admission purposes as it is already described inthe background part of the present invention. An other algorithm beingapplicable for the cumulative method is the so-called CUSUM algorithm.This is a statistical algorithm used in Statistical Quality Control forthe purpose of detecting a change in behavior of stochastic processes.There are a number of other algorithms used for similar purposes, forinstance Moving Average. Algorithms similar to moving average are usedfor flow control purposes in Internet transport protocols. However,these are merely examples and the present invention should not berestricted to any of these examples. More information about statisticalalgorithm are to be found in Basseville Michèle, Nikiforov Igor,Detection of Abrupt Changes: Theory and Application, Prentice-Hall,Inc., 1993 and in Carlstein E., Muller H.-G., Sigmund D. (ed.).Change-Point Problems. Institute of Math. Statist. Lecture NotesMonograph ser., V. 23, 1994;

It shall be noted that the values as such are not necessarily scalar,they can belong to any suitable value space, it can be discrete orcontinuous as well as multidimensional or of any other nature. Of courseadditional adaptation is needed for example in order to run timers.

Furthermore it is to be noted that the type of the cumulative algorithmto be used is usually determined at step S21, when initialisation of thewhole procedure is performed. That is at step S21 the decision is takenon which algorithm to use. However an on line algorithm which adaptsitself to the incoming data stream of user's usage measure (KeepAlive)can be of use. In this case new user's usage measure can trigger achange of the algorithm as such. If the selected type of the algorithmdepends on a number of parameters, said parameters can be eitherprovided on demand, or estimated based on any statistics/history. Theseparameters can be determined using the Least Square Fitting method, thatallows finding the best fitting parameters values to a given statisticaldata set/accumulated history, or any other appropriate method. Thealgorithm might be an autoregressive statistical algorithm as well.

Furthermore it is to be noted that the cumulative algorithm might be anautoregressive algorithm, which means that according to given parametersa decision is made, which algorithm is to be applied. Said parameterscan be either provided on demand, or estimated based on anystatistics/history.

Returning to FIG. 2, in subsequent step S25 it is tracked whether thenew updated resource usage measure justifies an action changing thestatus of the resource. The status of the resource can be either theresource is to be released, reserved or kept. Moreover this can be thereservation of an idle resource or the extension of the reservation of areserved resource. The purpose of the checking procedure is to check,whether any action condition is met in order to perform a resourcemanagement action. The checking might be performed in any suitable anddesirable way. For example it might be performed by means of acomparison function, comparing the resource usage measure with anysuitable action condition. For example whether the resource usagemeasure meets the action condition can be established from values ofdomains/sets. The resource usage measure can have a form of a singlescalar value or a vector. For example in the space of possible values ofresource usage measure three domains can be defined: domain D₁“release”, domain D₂ “reserve”, domain D₃ “keep reservation”, wherein D₂is part of D₃ and the action value can take three values “release”,“reserve/allocate” and “keep/extend allocation”, which could bedetermined using D₁, D₂, D₃. In principle these domains could be rathersophisticated, and methods of computational geometry (as for exampledescribed in Franco P. Preparata, Michael I. Shamos, ComputationalGeometry : An Introduction, Springer-Verlag, 1993) can be used to verifyto which domain the new value belongs, and which action shall be taken.Preferably the resource usage measure value is transformed to a positivescalar and a TTL timer is started. Anyhow these are merely examples forthe checking procedure used to decide about a resource managementaction.

Since in case the comparison's result states that the resource usagemeasure justifies a change, then an action is started changing thestatus of the resource, S26, e.g. by deciding to release or to reserveor to extend the reservation of the corresponding resource. Otherwise,when the result of the comparison is that the action value is notreached, the method proceeds to step S22, in which a new user's usagerequest is awaited.

In the following schematic signalling exchange between resource owner,resource user and resource broker according to FIG. 3 is described. Inthe first step, 31, the resource owner offers a resource, for example bysending an OFFER message to the resource broker. Preferably, saidmessage can carry an amount of parameters, such as Resource Type,Resource Identity, Availability Pattern or Keep Alive Flag, defining theavailability of the resource or informing about any planned down timeand time thereof or informing about the variation in time of theresource usage or informing about resource redundancy. Subsequent, theresource broker decides about its interest for management of the offeredresource. The decision is sent in the subsequent step 32 to the resourceowner by means of ACCEPT/REJECT MESSAGE informing about the metdecision.

In respect to FIG. 3 there is an interface between resource broker andresource user. The resource user informs for example by means of REQUEST(ResType, Usage Pattern) message, 3A, about its interest for the usageof the offered resource. As a reaction to the received request from theresource user, the resource broker validates the request and sendseither accept or reject message to the user, 3B. The usage of theresource is performed independent from the resource broker and directlybetween the resource owner and resource users, 35. The ACCEPT messagecontains resource descriptor, resource ID, etc. In fact the ACCEPTmessage can contain the time when according to the RB the resourcecan/will be seized for a common usage by a number of resource users, forinstance said message can contain the starting time of a multicastsession, which is estimated based on the resource users interest.

In the following an embodiment of the present invention is presentedaccording to FIG. 4 showing a flowchart of an embodiment of the presentinvention for releasing a shared resource. The following steps are to beperformed in order to decide about the release of a shared resource. Thefollowing embodiment is based on some examples for the measureparameters. However these examples should not be seen as a restrictionfor carrying out the present invention. In step S41, a TimeToLive TTLbeing an example for a resource usage measure is initiated. As alreadymentioned, the initiation of the resource usage measure can be performedin any desirable or suitable way. As also already mentioned in respectto FIG. 2 the usage measure could be for example Time To Use or money tospend in a certain period of time that is the combination (money, timeinterval). Alternatively the resource broker can adjust the Time To Live(TTL) timer of the resource on the basis of the received messages,events or delivered services, or historical knowledge. For instance incase of broadcast, multicast or anycast the TTL could be increased by adefault value whenever content is distributed to the group.

Subsequent to step S41, the method of FIG. 4 proceeds to step S44, inwhich a counter initiated with the TTL is started. The implementation ofsaid counter can be performed in any desirable or suitable way, forexample it may be just a counter without a relation to time, or it mayhave a relation to something else, such as processing capacity, cost ofthe resource or similar. IN the following we use a timer as an examplefor a counter, however this should not be seen as any restriction forthe present invention.

The purpose of said timer is to indicate time for keeping a resourcereserved. In the subsequent step S45 the running down of the timer isshown, whereby the running down is conveyed upon the timer achieved thevalue 0, S46. In this case the resource is released, S47. In thepresented embodiment, the steps S44, S45 and S46 build the general stepof checking the usage measure, as indicated in FIG. 2 in step S25.However, the running down timer is stopped by an incoming update messagefrom resource user, so that the current TTL equals the time left totimer's expiration. If there are no update messages from resource usersup to the timer expiration the TTL is set to zero, when the timerexpires. The just mentioned flow describes a case, when a usage measureis initiated and no user's usage measure message indicating the user'sinterest arrives. Herein the procedure goes via S44, S45, S46 and endsin S47 with the release of the resource, since no user seems to beinterested in having the resource reserved.

In the following the second part of FIG. 4 is presented, in which a KeepAlive message arrives, in step S42. According to the present inventionthe users are able to provide periodically a consistent estimation oftheir expected usage of the resource. Alternatively, this might bereleased administratively/manually, for example the resource brokerestimates the required reservation time based on the number of requestsper time period. Said estimation is sent to the resource broker by meansof the user's usage measure. Said measure may be implemented as KeepAlive message according to the embodiment of FIG. 4. Users sendKeepAlive messages to the resource owner in the service request messagesand periodically re-send it in appropriate messages before theirKeepAlive information expires. However, it is not really necessary toperiodically send a Keep Alive message. It is also possible thatKeepAlive messages are not sent periodically, but rather when theresource is actually required. The resource broker can request periodicKeepAlive updates from the resource user in the ACCEPT message when aresource is reserved. It should be further noted that KeepAliveinformation can also be denoted by the reception of content to bedistributed, without any dedicated KeepAlive indicators. The value ofuser's usage measure can have different values in different KeepAlivemessages sent from a resource user to its resource broker.

When KeepAlive arrives, S42, the method proceeds to step S43, wherein anupdating procedure for updating TTL with the received KeepAlive by meansof a cumulative algorithm is performed.

In the following an embodiment for the calculation of the new TTL bymeans of a cumulative algorithm based on the Leaky Bucket approach isdescribed.

As already mentioned the cumulative algorithm considers the past valueof the resource usage measure and additionally the current needs of theusers. Thus, in this example a Total_KeepAlive value is updated by meansof a Model Function, fct, in thatTotal_KeepAlive(n+1)=fct(Total_KeepAlive(n),KeepAlive, . . . )

wherein in respect to the Leaky Bucket approach the above formula hasthe following formTotal_KeepAlive(n+1)=MIN(Total_KeepAlive(n)−ΔTTL+KeepAlive*weight,MAX_Total)

wherein

Total_KeepAlive(n) describes the current resource usage measurecumulating its past values;

ΔTTL is the time expired after the last TTL update;

weight may depend on the user's identity or category considering somekind of prioritisation;

MAX_Total defines the total capacity of a Leaky Bucket.

The new estimated Total_KeepAlive(n+1) value is used to determine a newTTL, whereinTTL=Total_KeepAlive(n+1)−ReasonToLive

The ReasonToLive value influences the time point of resource release.Consequently, the higher the ReasonToLive value the faster a decision torelease the resource is made.

As in FIG. 4 indicated in step S44, the timer, which was initially setto TTL is updated with the new calculated TTL and said timer starts torun.

In the following, in order to explain the above introduced parameterswith regard to Leaky Bucket, an embodiment for the calculation of theTTL in respect to FIG. 8 is given.

FIG. 8 shows a schematic representation of the Leaky Bucket algorithm.The Leaky Bucket has an upper value, which is the MAX_Total indicatingthe maximal value that can be assigned to Total_KeepAlive.

It is to be noted, that there might be further parameters controllingthe Leaky Bucket, for example a maximal number of incoming KeepAlivemessages per given time interval might be introduced in order to provideoverload protection in resource broker.

The bottom of said Bucket builds the ReasonToLive value, which showswhen a resource being administrated by means of this bucket can bereleased. The upper arrow coming into the bucket indicates the incomingKeepAlive messages. The outgoing arrow indicates the dropping of the TTLtimer.

As described above, the timer being set to TTL counts down. According toFIG. 8 said timer is updated to a higher value when a new KeepAlivemessage arrives, meaning that the fullness of the bucket increases.Otherwise when no new KeepAlive messages arrive, the timer achieves thezero level meaning that the resource is to be released.

It should be noted that the settings of configuration parameters, suchas ReasonToLive, MAX_Total, weight, as well as selection of theModel_function depends on actual needs and could vary from case to case.In particular, it is to be emphasized that this function can considerfurther parameters, like for example resource costs, resourceavailability etc. Since the above-described steps of calculation aresimilar to the CUSUM algorithm the developed Statistical methods forbuilding the CUSUM model all could be of use to determine the modelparameters.

Furthermore, it should be noted that by selecting the model function oneis able to adjust the algorithm for different use cases, for instancethe algorithm can also consider whether there is one or multiple unitsthat use the resource (e.g. multiple sources distributing content to amulticast group) and adapt the TTL accordingly. In case of multiplesources, the algorithm can calculate equal cost shares for the contentproviders, for instance in case of distribution of commercials where thecontent provider (and usually not the content receiver) pays. Providinga higher TTL implies a higher relative cost.

It should be also noted that the KeepAlive values are stored togetherwith the content sender identifiers for charging purposes, so that anappropriate charging for the resource being used or kept open can beachieved. The invention also enables the charging of the time that aresource is reserved but not used by the resource users.

According to FIG. 8 there is also a ReasonToReserve value indicating apossible value for allocating a new resource, as it is described in anembodiment in respect to FIG. 5.

Returning to FIG. 4, it was said that the timer is set to the newupdated TTL value and started to run, S43. The implementation of saidtimer can be performed in any desirable or suitable way. For example itcan count down time units. The counting down can also consider theactual usage of the resource. For example the decrease of the countercan go faster when more bandwidth is used, this is achieved byscaling/weighing correctly the TTL prior to starting the timer. Insubsequent step, S44, the running timer is shown. Said timer is checkedperiodically, whether it achieves a pre-determined value, step S45. Inthis embodiment the pre-determined value is set to 0. However, everyexperienced value might be applied. In case the timer has achieved apre-determined value, then the resource is released. Otherwise theprocedure returns to step S44, from which an arrow provides also tostep, S47, in which a new KeepAlive message is awaited.

It should be noted that the resource release procedure can beimplemented in different ways depending on the kind of the resources.For example if the resource is a memory at the server then a certaininformation is to be sent to said server informing about resourcerelease.

In the following an embodiment of the present invention is presentedaccording to FIG. 5 showing a flowchart of an embodiment of the presentinvention for performing resource allocation. The following steps are tobe performed in order to make a corresponding decision.

In step S51 a resource usage measure is initiated with a pre-determinedvalue, which is in this case 0. Subsequent to step S51, the method ofFIG. 5 proceeds to step S56, which is conducted until a request from auser is received. Said request is expressed in this embodiment asInterestMsg indicating the interest of users for certain kind ofresource. In order to be able to send the InterestMsg, the users are tobe informed about the possibility for the allocation of this resource.This can be done for example by means of a broadcast message being sentfrom the resource owner to the potential users. However, there are anumber of known methods for informing users about a new hardware orservices, so that these are not described herein.

In the subsequent step, S53, the resource broker performs an updateprocedure for updating the resource usage measure with the InterestMsgby means of a cumulative function.

In the following embodiment of a cumulative function in a resourcereservation model, Total Interest denotes the resource usage measurereferring to the interest measure. In this example a Total_Interestvalue is updated by means of a Model Function, fct2, in thatTotal_Interest(n+1)=fct2(Total_Interest(n),InterestMsg, . . . )

The corresponding Model function might have the following form:Total_Interest(n+1)=MIN(MAX(Total_Interest(n)−ΔTTL,0)+InterestMsg*weight,MAX_Total)

wherein

Total_Interest(n) describes the current resource interest measure;

ΔTTL is the time expired after the last Total_Interest update;

weight may depend on the user's identity or category considering somekind of prioritisation;

MAX_Total defines the total capacity of a Leaky Bucket and is the sameas in the resource release model above.

It is to be noted, that for some resource reservation models there is noneed to start timers, it depends on the Interest patterns provided byusers in the InterestMsg. However in some cases the time passed afterthe last update shall be considered as it is pointed out in theabove-mentioned example by including in the model the ΔTTL parameter.

Another example of the model function can be a moving average likefunction:Total_Interest(n+1)=T_Weight(n)*Total_Interest(n)+weight*InterestMsg

wherein

T_Weight(n) is the (smoothing) parameter that at each step adjusts theTotal_Interest(n)

Users can send InterestMsg periodically or only once when the number ofusers is counted. However, this should not be seen as a restriction forthe present invention. However, with the update procedure the cumulativeinterest for a specific resource is estimated. After each update saidvalue is compared with a pre-defined ReasonToReserve value, S54. In casesaid value is achieved a procedure for allocation of a resource isstarted. Otherwise the procedure returns to the state, S56, in which anext InterestMsg is awaited.

Preferably, it is proposed to start the resource release method, whenresource has been allocated according to the above described procedure.In this case the Total_KeepAlive(0) is initialised either by the currentTotal_Interest(n+1) value or by any other appropriate value, whereas theTTL is initialized with Total_KeepAlive(0)−ReasonToLive, or any otherappropriate value.

In the following an embodiment of system architecture and interfacesaccording to the present invention in respect to FIG. 6 is presented.FIG. 6 shows a schematic representation of a system for broadcast ormulticast content provision, in which content providers CP representresource owners and the resource is the shared communication networkdistributing the content among a number of users being in this contextcontent receivers CR. Further as already mentioned the shared resourcecan be also a multicast group. According to the present invention theresource broker hosts the leaky bucket algorithm for each resource to bemanaged. Between the content providers CP and content receivers CS thereis the resource broker RB administrating the shared resources. Furtherin respect to FIG. 6 there are query interfaces between the resourcebroker and the content providers. By means of the logical connection 6C,content providers send the content to the resource broker.

In this embodiment the real resource usage goes via the resource broker,so that the said resource broker is able to control the traffic.

Preferably, the resource broker also provides query interfaces towardsthe content providers, 6B and 6A. Said interfaces are utilized forquerying parameters needed for performing the procedure for managingresource. In the following some examples are given to illustrate whichparameters can be exchanged between the communicating instances. Forexample over the 6A interface a request information about theavailability of the resource, like for example whether the resource hasalready been established, might be queried. This query is typically usedfor non time critical content that is preferably distributed when theresource is already established by another content provider, for exampleat a reduced cost. Further in order to ensure an appropriate workingupdate procedure, some additional parameters or more precise estimatedparameters might be queried. In a particular embodiment, requestinformation about the leaky bucket parameters, such as ReasonToLive,number of resource users, might be ordered. Furthermore the resourcebroker might require information about resource characteristics, likefor example available bandwidth, QoS, costs for the reservation and/oractual usage of the resource at the moment (since the cost may depend onthe number of simultaneous resource users) in order to set theparameters affecting the decision about reservation/allocation orrelease of resource in a better way. The management procedure formanaging resources might need further parameters in order to set itsparameters in a better way. For example the parameters of the updateprocedure might depend on the resource cost, which can influence theleaky bucket state.

Instead of having the content providers query the resource broker, thecontent providers may also be notified by the resource broker,preferably when they have registered for the corresponding informationdistribution. This communication can be performed by means of the 6Binterface. For example the resource broker may send a message thatsomeone just established a resource of type ‘X’ and there is still ‘Y’amount of bandwidth available.

Preferably the resource usage information is stored and sent to chargingservers, which can use this information to establish better costdistribution among the resource users (even for the time when theresource is just reserved but not actually used) of the resource. Thiskind of communication is denoted as 6D in FIG. 6.

However these are merely examples showing that by means of interfacesadditional information might be queried to ensure a better performanceof the resource management procedure according to the present invention.

1. Method for management of a resource for a communication networkhaving a resource owner (RO) providing the resource, at least oneresource user (RU) using the resource and a resource broker (RB) formanaging the resource, characterized in that the resource broker (RB)performs the following steps: initiating a resource usage measure (TTL)controlling a reservation of the resource, obtaining a user's usagemeasure (Keep Alive, Interest Msg) informing about the estimated usageof the resource by the at least one resource user, performing an updateprocedure for updating the resource usage measure (TTL) with the user'susage measure (Keep Alive, Interest Msg) by means of a cumulativealgorithm averaging the resource usage measure and calculating a newresource usage measure by taking into account current and past values ofthe resource usage measure (TTL) and the user's usage measure performinga checking procedure for comparing the resource usage measure with apre-determined value indicating the necessity to perform a resourcemanagement action, and performing the resource management actionaccording to the result of the checking procedure.
 2. Method accordingto claim 1, characterized in that the resource is embodied as asequentially shared resource, wherein only one resource user accessesthe resource at the same time or the resource is embodied as asimultaneously shared resource, wherein multiple resource users mayaccess the resource at the same time.
 3. Method according to claim 1 or2 characterised in that the resource usage measure is initiated with avalue being estimated from at least one parameter received from theresource owner.
 4. Method according to claim 1 or 2 characterised inthat the resource usage measure is initiated with a value beingdetermined at the resource broker.
 5. Method according to one of theclaims 1 to 4 characterised in that the initiation step includesproviding of an association between the resource and information relatedto said resource.
 6. Method according to one of the claims 1 to 5characterised in that the resource usage measure is set to a valuedefining time for keeping the resource open.
 7. Method according toclaim 1 characterised in that the user's usage measure is being receivedperiodically from the at least one resource user.
 8. Method according toclaim 7 characterised in that the user's usage measure is being receivedfrom the at least one resource user on demand depending on the resourceuser's needs.
 9. Method according to claim 1 characterised in that theuser's usage measure is calculated in the resource broker.
 10. Methodaccording to one of the claims 1 to 9 characterised in that arecognition procedure is performed in the resource broker in order torecognise a relation between the at least one resource user and thecorresponding resource, its owner and the management procedure. 11.Method according to claim 1 characterised in that a Leaky Bucketalgorithm or a CUSUM algorithm is used as cumulative algorithm. 12.Method according to claim 1 characterised in that the resourcemanagement action is allocating of the resource, keeping of the resourceor release of the resource.
 13. Method according to claim 1characterised in that the checking procedure is performed by comparingthe resource usage measure with an action condition.
 14. Methodaccording to one of the claims 1 to 13 characterised in that said methoduses additional information received over a first interface placedbetween resource broker and resource owner.
 15. Method according to oneof the preceding claims 1 to 14 characterised in that a timer is set tothe resource usage measure and said timer is started to count down time,wherein said timer is checked for necessity to perform release of theresource.
 16. Method according to one of the preceding claims 1 to 14characterised in that the resource measure indicates interest of the atleast one resource user to perform allocation of the resource. 17.Method according to one of the claims 1 to 16 characterised in that anadditional interface is introduced to exchange information with acharging entity wherein the resource broker provides the resource usagemeasure to the charging entity for charging (page 13 lines 9-10). 18.Method according to claim 17 characterised in that for the charging,time is estimated in that a resource has been reserved but not reallyused.
 19. Method according to claim 17 or 18 characterised in that forthe charging information about number of multiple resource users sharinga resource is estimated.
 20. Method according to claim 1 characterisedin that a real resource traffic goes via said resource broker. 21.Resource broker arranged to perform management of a resource for acommunication network having a resource owner (RO) providing theresource and at least one resource user (RU) using the resourcecharacterized in that said resource broker comprises initiation meansfor initiation of a resource usage measure (TTL) controlling areservation of the resource; and an obtaining controller for obtaininguser's usage measure (Keep Alive, InterestMsg) informing about theestimated usage of the resource by the at least one resource user; anupdate controller for updating the resource usage measure (TTL) with theuser's usage measure (Keep Alive, InterestMsg) by means of a cumulativealgorithm averaging the resource usage measure and calculating a newresource usage measure by taking into account current and past values ofthe resource usage measure (TTL) and the user's usage measure; achecking monitor for comparing the resource usage measure with apre-determined value indicating the necessity to perform a resourcemanagement action; and resource management action means for performingresource management action according to the result of the checkingmonitor.
 22. Resource broker according to claim 21 characterised in thatsaid resource broker has a first communication means for interactionwith a first communication interface being placed between said brokerand the resource owner and a second communication means for interactionwith a second communication interface being placed between said brokerand the at least one resource user.
 23. Resource broker according toclaim 21 or 22 characterised in that said resource broker has a thirdcommunication means for interaction with a third communication interfacebeing placed between said broker and a charging unit.
 24. Resourcebroker according to one of the claims 21 to 23 characterised in thatsaid resource broker is adapted to provide unreliable resources forbrokering.
 25. System for management of resource for a communicationnetwork having a resource owner (RO) providing the resource and at leastone resource user (RU) using the resource, wherein said system comprisesa resource broker (RB) according to claim 21 being introduced betweenthe resource owner (RO) and the at least one resource user (RU) and afirst communication interface between said resource broker (RB) and theresource owner (RO) and a second communication interface between saidresource broker (RB) and the at least one resource user (RU)characterised in that the resource broker is adapted to perform themethod according to claim
 1. 26. System according to claim 25characterised in that said system includes a charging unit and a thirdcommunication interface between resource broker and said charging unit.